Product documentation
This section introduces the core concepts and architecture of HSO Service Management for Microsoft Dynamics 365 for Finance and Operations. It explains the key components, their relationships, and how they support end-to-end service processes and integrate with Microsoft Dynamics 365 for Finance and Operations.
Introduction
HSO Service Management is an integrated solution for Microsoft Dynamics 365 for Finance and Operations, designed to support organizations that provide maintenance, repair and other service-related activities for customer equipment, installations and assets.
The solution supports the complete service lifecycle, from managing service objects and customer agreements to registering service requests, planning and executing work, and processing the associated costs and revenues.
By combining operational service processes with the standard capabilities of Microsoft Dynamics 365 for Finance and Operations, HSO Service Management provides a centralized environment for managing service activities, maintaining service history and supporting financial control.
Key capabilities
HSO Service Management provides the following core capabilities:
Service Objects – Register and maintain customer equipment, installations and assets, including their structure, components, identification details, warranty information and service history.
Service Calls – Register and manage service requests, complaints, breakdowns and other service activities throughout their lifecycle.
Service Tasks & Operations – Define, plan, execute and register service work, including labor, materials, costs and detailed operations.
Planning & Scheduling – Assign service activities to technicians and other resources based on availability, capacity and required capabilities.
Service Contracts – Manage customer service agreements, including contract coverage, service levels, pricing and invoicing arrangements.
Preventive & Planned Maintenance – Plan recurring maintenance activities based on predefined schedules, maintenance requirements or meter readings.
Service Quotations – Prepare quotations for service activities before the work is approved and executed.
Repair Centre – Support workshop-based repair processes, including the handling and repair of equipment.
Invoicing & Financial Integration – Process service-related costs and revenues using the standard financial and project accounting capabilities of Microsoft Dynamics 365 for Finance and Operations.
Integration with Microsoft Dynamics 365 for Finance and Operations
HSO Service Management operates within Microsoft Dynamics 365 for Finance and Operations and uses several standard modules to support service processes.
An important part of this integration is Project Management and Accounting. Service objects can be associated with projects, while service calls can generate subprojects. Service-related transactions, such as labor, materials and expenses, are recorded through the project accounting framework.
Other integrations include:
Inventory and Warehouse Management for material consumption, item availability and repair logistics.
Finance for financial postings, cost allocation and revenue recognition.
Resource Management for technician assignments, resource availability and capacity planning.
Sales for processes involving equipment lists, service quotations and delivered equipment.
This integration allows service organizations to manage operational activities and their financial consequences within the same business environment.
Supporting the complete service lifecycle
A typical service process starts with a registered service object representing the equipment or installation requiring service. When a customer requests assistance, a service call is created. Depending on the nature of the request, one or more service tasks can be planned and assigned to the appropriate resources. During execution, technicians or service personnel register the work performed, materials consumed and any relevant measurements or operations.
Once the work has been completed, the associated transactions can be processed financially according to the applicable service contract, warranty conditions and invoicing arrangements. Throughout this process, the service history remains associated with the relevant service object, providing visibility into previous activities, maintenance and repairs.
Related HSO solutions
HSO Service Management can be used alongside other HSO solutions, including Mobile Field Service and Rental Management. These solutions provide additional capabilities for specific business scenarios and are documented separately where their functionality or configuration differs from the standard Service Management solution.
Introduction
HSO Service Management supports the complete service process, from the initial service request or planned maintenance requirement through planning, execution, completion and invoicing. Each stage is connected through a set of core entities, ensuring that operational activities, financial transactions and service history remain linked to the relevant customer and service object.
Although the exact workflow depends on the type of service, contractual agreements and organizational requirements, the following stages represent a typical end-to-end service process.
Service Object identification
The service process starts with identifying the equipment, installation or asset requiring service. In HSO Service Management, this is represented by a Service Object.
A Service Object contains relevant information such as the customer, object type, serial number, service address, warranty conditions, components and service history. It may also be associated with a Service Contract defining the applicable service levels and commercial conditions.
Correct identification of the Service Object is essential, as it determines much of the information used throughout the service process.
Service Request and Call registration
When a customer reports a problem or requests service, a Service Call is created. The Service Call represents the overall service request and provides the administrative and operational context for the work to be performed.
During registration, the relevant Service Object, customer, Service Contract and Call Type are identified. Depending on the configuration, contract coverage, warranty conditions and project integration settings can influence the subsequent processing of the call.
Service Calls may also originate from planned or preventive maintenance activities rather than a direct customer request.
Service Task creation
Once the Service Call has been registered, one or more Service Tasks can be created to define the actual work required.
A Service Task represents an individual unit of work and may include expected labor, required materials, service operations and other forecasted costs or activities. Event Codes and predefined templates can be used to standardize the work content and automatically populate relevant information.
Multiple Service Tasks can be associated with a single Service Call, allowing different activities to be planned and executed independently while remaining part of the same service request.
Planning and scheduling
Service Tasks are planned and assigned to appropriate resources, such as field technicians, workshop employees or maintenance engineers.
Planning takes into account resource availability, required capabilities, customer commitments, task priority and the expected duration of the work. Depending on the configuration, additional considerations such as travel, material availability and resource capacity may influence scheduling. Once scheduled, the Service Task can be dispatched for execution.
Service execution and registration
During execution, the assigned resources perform the required service activities and register the actual work carried out. Registrations may include:
Labor hours and related costs.
Materials and spare parts consumed.
Additional expenses and travel costs.
Service Operations and inspection results.
Meter or counter readings.
Relevant findings and service notes.
These registrations provide the operational details required to track progress, maintain the service history and determine the financial consequences of the work.
Task completion and Service Call closure
After the required work has been performed and registered, the Service Task can be completed through the applicable task status and realization process.
A Service Call can be closed once the required closing conditions have been satisfied. Typically, this includes ensuring that the related Service Tasks have reached the appropriate completion status and that mandatory information has been recorded.
Depending on the configuration, closure can be initiated manually or triggered automatically through the Service Call status workflow.
Financial processing and invoicing
HSO Service Management is integrated with the Project Management and Accounting functionality of Microsoft Dynamics 365 for Finance and Operations. Service-related transactions are processed through the project accounting framework, allowing costs and revenues to be recorded against the appropriate projects.
The financial treatment of service activities depends on factors such as contract coverage, warranty conditions, project integration settings and the applicable pricing arrangements.
After operational completion and closure of the Service Call, an invoice proposal can be generated, reviewed and posted where invoicing is required. Invoicing may also be processed in batches.
Service history and follow-up
Throughout the service process, relevant information is retained in relation to the Service Object, providing a history of service requests, completed activities, repairs and maintenance.
This information supports future service activities by giving users access to previous work, registered measurements and relevant operational details. It also provides a foundation for evaluating equipment performance and planning subsequent maintenance.
Process summary
The typical end-to-end service process can be summarized as follows:
Service Object → Service Call → Service Task → Planning & Scheduling → Execution & Registration → Completion & Closure → Financial Processing & Invoicing
Service Contracts, warranty conditions and project integration settings influence the process at various stages.
Not every service scenario follows exactly the same sequence. Preventive maintenance, workshop repairs and contract-based services may introduce additional activities or alternative workflows. These processes are described in more detail in the corresponding sections of this documentation.
Introduction
HSO Service Management is built around a set of interconnected entities that support the complete service lifecycle. These entities represent the equipment being serviced, the contractual agreements with customers, the service requests received and the activities required to perform and complete the work.
Understanding the purpose and relationships of these entities is essential for configuring and using the solution effectively. Together, they provide a consistent structure for managing service activities, recording operational information and processing financial transactions within Microsoft Dynamics 365 for Finance and Operations.
Service Objects
A Service Object represents an individual asset, installation or piece of equipment for which service activities are performed. It is the central entity for maintaining equipment-related information, including identification details, customer relationships, service addresses, warranty conditions and service history.
Service Objects can exist independently or form part of a larger Object Structure containing multiple objects and components. Where separate financial or logistical tracking is required, individual Service Objects can be associated with projects.
Object Structures & Components
An Object Structure represents the hierarchical relationship between Service Objects and their components. It allows complex installations or equipment configurations to be represented at different levels.
Components identify operationally relevant parts of a Service Object without requiring separate financial or logistical project tracking. Service Operations can be associated with these components to record specific inspections, checks or activities.
Service Object Pools
Service Object Pools allow multiple similar objects to be managed collectively when individual financial tracking is not required. A pool can represent a group of equipment sharing common service conditions, such as customer, service location or warranty terms. Service activities, costs and revenues can be tracked at pool level rather than separately for every individual unit.
Service Contracts
A Service Contract defines the commercial and operational agreement between the service organization and its customer. It specifies which Service Objects are covered, the applicable service conditions and the financial arrangements. Contracts can include coverage definitions, service levels, maintenance schedules, pricing arrangements and periodic invoicing schedules.
Service Calls
A Service Call represents a service request or case and provides the central record for managing the request from registration through operational completion and financial closure.
The Service Call connects the customer, Service Object, applicable contract conditions and related Service Tasks. It also maintains information about the request, its classification, progress and handling history. A single Service Call can contain multiple Service Tasks when several activities are required to resolve the request.
Service Tasks
A Service Task represents an individual unit of work performed as part of a Service Call. Tasks contain the operational information required for planning, scheduling, execution and registration.
Each Service Task can include forecasted and actual labor, materials, costs, travel, revenue and Service Operations. Tasks are assigned to resources and progress through their operational lifecycle independently, while remaining linked to their parent Service Call.
Event Codes
Event Codes define reusable packages of service work, such as inspections, maintenance, repairs, installations or replacements. In combination with the Object Type, an Event Code can determine the forecasted work content of a Service Task, including expected duration, materials, operations and revenue. This supports consistent task creation and standardization of recurring service activities.
Service Operations & Meters
Service Operations represent specific activities, inspections or checks performed on components of a Service Object. They provide a structured way to record the execution and results of detailed service work.
Meters and Counters record measurements associated with equipment components. Their historical readings can be used to monitor equipment usage and support meter-based maintenance activities.
Coverage Types & Service Level Definitions
Coverage Types define the rights and obligations associated with service agreements, such as included maintenance, covered labor or other contractual benefits.
A Service Level Definition (SLD) combines the applicable coverage with settings such as allowed Call Types, the default Call Type and Project Integration. These settings influence how Service Calls are created and how their financial transactions are processed.
Project Integration
Project Integration connects service activities with the Project Management and Accounting functionality of Microsoft Dynamics 365 for Finance and Operations. Service Objects can be linked to projects, while Service Calls can create subprojects. Service-related transactions are processed using the appropriate project categories and line properties, allowing operational activities to be translated into financial costs and revenues.
Relationships between the core entities
The main relationships can be summarized as follows:
A Service Object represents the equipment or installation being serviced and may belong to an Object Structure or Service Object Pool.
A Service Contract defines the applicable contractual conditions for covered Service Objects.
A Service Call represents the service request and connects the customer, Service Object and applicable service conditions.
A Service Call can contain one or more Service Tasks, each representing a specific unit of work.
An Event Code, together with the Object Type, can determine the forecasted work content of a Service Task.
Service Operations record detailed activities, while Meters and Counters maintain measurement history.
Project Integration connects the operational service process to financial processing within Microsoft Dynamics 365 for Finance and Operations.
Together, these entities establish the foundation for a traceable service process, from the initial customer request through execution, completion and invoicing.
Introduction
In HSO Service Management, the term Service Object is used to identify an entity on which service activities are performed. Although a Service Object often represents a physical asset, the two terms are not necessarily interchangeable.
The concept of a Service Object is broader than the traditional definition of an asset. It allows organizations to register and manage service activities for physical equipment, complete installations, individual components and even non-physical entities.
What is a Service Object?
A Service Object represents an entity that can be serviced, maintained, repaired or inspected. It provides the operational context for service activities and maintains relevant information such as identification details, customer relationships, service addresses, warranty conditions and service history.
Depending on the business requirements, a Service Object can represent:
A site or location – Such as a building or facility where service activities are performed.
An installation – A complete installation consisting of multiple pieces of equipment or components.
An individual physical item – Such as a machine, vehicle or device identified by an item number, serial number, chassis number or license plate.
A group of similar items – Equipment managed collectively because individual financial tracking is not required.
An interchangeable component – A component of a larger installation that requires its own service and financial history.
A non-physical entity – Such as a software license that requires service-related administration.
This flexibility allows the service model to reflect the actual structure and requirements of the organization.
What is an Asset?
The term Asset is commonly used to describe physical equipment, machinery, vehicles, installations or other resources that have operational or economic value. In a service organization, an asset is typically something that requires maintenance, inspection or repair during its operational lifetime.
Within HSO Service Management, such an asset can be represented by a Service Object. However, not every Service Object needs to correspond to a separately identifiable physical asset.
The key difference
The main distinction is that an Asset describes the equipment or resource itself, while a Service Object represents the entity against which service activities are managed and recorded.
For example, an industrial installation may be considered a single asset from a business perspective. Within HSO Service Management, the same installation can be represented by a hierarchy of Service Objects, allowing individual machines or replaceable units to have their own service history. Alternatively, multiple similar items can be managed collectively through a Service Object Pool when individual tracking is unnecessary.
Service Objects and Components
Not every part of an installation needs to be registered as a separate Service Object. Components are used to represent operationally relevant parts of an Object Structure that do not require their own financial or logistical project tracking. Service Operations, inspections and measurements can be registered against these components.
When a component requires independent tracking of service activities, costs or replacement history, it can instead be represented as a separate Service Object within the hierarchy.
Why the distinction matters
Choosing the appropriate level of Service Object registration is important for maintaining accurate service information and supporting the correct operational and financial processes.
The Service Object structure influences how service history is maintained, how Service Calls and Tasks are associated with equipment, and how project-related costs and revenues are tracked.
A well-designed Service Object model therefore provides the foundation for consistent service execution, contract management and financial integration within Microsoft Dynamics 365 for Finance and Operations.
Introduction
Within HSO Service Management, Service Calls and Service Tasks serve different purposes but are closely related. A Service Call represents the overall service request or case, while a Service Task represents a specific unit of work required to handle that request.
This distinction allows service organizations to manage customer requests separately from the individual activities performed by technicians or other resources.
What is a Service Call?
A Service Call is the central record for registering and managing a service request from initial contact through resolution and financial closure. It acts as a case file containing the operational, contractual and financial information associated with the request. Service Call supports several activities, including:
Registering customer and Service Object information.
Classifying the request using a Call Type and severity.
Determining the applicable Service Contract, service level and coverage.
Monitoring progress, milestones and service-level commitments.
Recording customer interactions and handling history.
Managing related Service Tasks and financial transactions.
Closing the request and processing invoicing.
A Service Call does not necessarily require a Service Task. For example, a customer inquiry may be resolved directly by the service desk without requiring a technician to perform any work. Depending on the request, other follow-up activities, such as creating a Sales Order or Purchase Order, may also be appropriate.
What is a Service Task?
A Service Task represents a specific work assignment that is planned, executed and reported back as part of a Service Call. It provides the operational instructions and transaction details required for the assigned resource to perform the work.
Service Tasks can be assigned to field technicians, workshop employees, maintenance engineers or other resources. Each task can contain forecasted and actual information relating to labor, materials, expenses, travel, revenue and Service Operations.
An Event Code is typically used to identify the type of work and, together with the Object Type, can determine the forecasted work content.
Service Tasks can also be dispatched to Mobile Field Service (MFS), the mobile application used by service engineers to execute and report their assigned work. Through MFS, engineers can access relevant task information and register their activities in the field. The reported information is subsequently synchronized with HSO Service Management for further processing. Mobile Field Service functionality is described separately in the online documentation.
Unlike a Service Call, a Service Task cannot exist independently. Every Service Task must be associated with a parent Service Call.
The relationship between Service Calls and Service Tasks
A single Service Call can contain multiple Service Tasks. This is particularly useful when resolving a request requires several visits, different types of work or multiple resources.
For example, a customer reports a malfunctioning machine. A Service Call is registered to capture the problem and monitor its resolution. An initial Service Task is created for diagnosis. If additional repair work is required, another Service Task can be created under the same Service Call. Each Service Task can be planned, executed and completed separately, while the Service Call remains the central record for monitoring the overall request.
Service Call and Service Task statuses
Service Calls and Service Tasks have separate status management mechanisms. Service Call statuses are used to monitor the overall progress of the request. The workflow and associated status behavior can be configured to reflect the organization's service processes. Service Tasks use a defined set of seven operational statuses:
Quotation – The task has been created and can be quoted.
Confirmed – The work has been confirmed and is ready for scheduling.
Scheduled – A time slot and resource have been assigned.
In process – Execution has started and actual work can be registered.
Registered – Work registrations have been recorded and may require further processing.
Ready – The task has been realized and completed.
Cancelled – The task has been cancelled, subject to applicable restrictions.
These statuses support the operational lifecycle of a Service Task, from initial preparation and planning through execution, registration and completion.
Automatic Service Call status updates
The status of individual Service Tasks can also influence the status of their parent Service Call. Through the configurable Call status updates setup, rules can be defined to automatically change the Service Call status when a Service Task reaches a particular status.
These rules can take several conditions into account, including Call Type, Repair Status, Priority, MFS Status and Event Code. For example, when a Service Task for an Inspection reaches the Ready status, the associated Service Call can automatically be updated to Completed.
This mechanism allows organizations to automate Service Call progress based on Service Task execution, while maintaining control over the overall service process.
Automatic status updates should be distinguished from Service Call closure. Typically, all related Service Tasks must be Ready and any mandatory closing information must be completed before a Service Call can be closed.
The configuration of automatic status updates is described in more detail in the Setup & Configuration section of this documentation.
Operational and financial responsibilities
The Service Call provides the overall context for the customer request, including contract coverage, service levels, progress monitoring and invoicing.
Service Tasks contain the detailed work registrations that generate operational and financial transactions. These transactions are processed through the Project Management and Accounting functionality of Microsoft Dynamics 365 for Finance and Operations.
This separation enables organizations to monitor the overall service request while maintaining detailed control over individual work assignments, resource utilization and associated costs.
Summary
The distinction between a Service Call and a Service Task can be summarized as follows:
Service Call – What has been requested, by whom, for which Service Object, under which conditions and with what overall result?
Service Task – What work needs to be performed, by which resource, when, and what activities and transactions have been registered?
Together, Service Calls and Service Tasks provide the foundation for managing service requests and their execution within HSO Service Management.
Introduction
Within HSO Service Management, Service Tasks and Service Operations represent two different levels of service execution. A Service Task defines the overall work assignment, while Service Operations describe the individual activities, inspections or measurements that must be performed as part of that assignment.
Together, they provide a structured approach to planning, executing and documenting service work, from the assignment of a technician to the registration of detailed results against individual Service Object components.
What is a Service Task?
A Service Task represents a unit of work assigned to a service engineer or other resource. It is always associated with a Service Call and provides the operational context for executing and reporting the required work. A Service Task typically includes information such as:
The Service Object on which the work must be performed.
The Event Code identifying the type of work.
The assigned resource and planned execution time.
Forecasted and actual labor, materials, travel and other costs.
The Service Operations to be performed.
The progress and completion status of the assignment.
Service Tasks can be scheduled and dispatched to resources, including service engineers using Mobile Field Service. The engineer performs the assigned work and reports the results, after which the Service Task can be processed and completed. A Service Task may contain multiple Service Operations, depending on the nature and complexity of the work.
What is a Service Operation?
A Service Operation represents a specific activity to be performed and the formal registration of its execution. Unlike a Service Task, which manages the overall work assignment, a Service Operation focuses on an individual activity or check associated with a Service Object component. Service Operations can be used to define and record activities such as:
Inspections and condition checks.
Measurements and calibration results.
Functional tests and verification procedures.
Component exchanges.
Counter or meter readings.
Other predefined maintenance or service checks.
A Service Operation can contain instructions for the activity and record the corresponding execution feedback and return values. This allows organizations to standardize recurring service activities and maintain consistent records of the work performed.
The relationship between Service Tasks and Service Operations
Service Tasks and Service Operations work together within the service execution process.
A Service Task defines the overall assignment, including when the work should be performed, which resource is responsible and which materials or other transactions are required.
Service Operations define the individual activities that form part of that assignment. They provide a structured way to specify what needs to be checked or performed and to record the corresponding results.
For example, a Service Task is created to perform preventive maintenance on an industrial installation. The task may contain several Service Operations, such as checking operating pressure, inspecting a filter, verifying a safety mechanism and recording a meter reading. The Service Task manages the maintenance visit as a whole, while each Service Operation documents a specific part of the work.
Service Operations and Service Object components
An important characteristic of Service Operations is their relationship with Service Object components. Service Operations are performed on components within the Service Object structure. Their execution is registered against both the relevant sub-object and component, allowing the system to retain detailed service history.
This is particularly valuable when components are exchanged or moved between Service Objects. The registered operation history remains associated with the relevant component, preserving information about previous inspections, measurements and maintenance activities. As a result, organizations can maintain a more detailed technical history than would be possible through Service Task registrations alone.
Execution feedback and return values
Service Operations support the formal registration of execution results. Depending on the operation, the technician may need to provide feedback or record a specific return value.
For example, an inspection operation may require a condition assessment, while a measurement operation may require a numerical reading. Other operations may involve predefined reference values or confirmation that a particular activity has been completed.
These registrations provide a consistent record of the technical work performed and can be reviewed through the registered Service Operations inquiries.
The configuration of Service Operations and their return values is described in more detail in the relevant setup and execution sections of this documentation.
Operational and financial differences
Service Tasks provide the main framework for planning resources and registering operational and financial transactions, including hours, materials, expenses, travel and revenue. Service Operations focus primarily on the technical execution details and the results recorded against Service Object components.
This distinction separates the management of a work assignment from the detailed technical evidence of the activities performed.
Both levels contribute to the overall service history, but serve different reporting purposes. Service Task registrations provide insight into resources, work performed and associated transactions, while registered Service Operations provide detailed information about inspections, measurements and other component-level activities.
Summary
The distinction between a Service Task and a Service Operation can be summarized as follows:
Service Task – What work must be performed, by which resource, when, and what operational and financial transactions are involved?
Service Operation – Which specific activity or check must be performed on a component, and what result has been recorded?
Together, Service Tasks and Service Operations allow HSO Service Management to manage both the execution of service assignments and the detailed technical history of the work performed.
Introduction
Within HSO Service Management, Service Contracts define the rights and obligations agreed between a service organization and its customers. These agreements determine which Service Objects are covered, which services are provided, under which conditions service requests are handled and how the associated costs and revenue are processed.
Service Contract entitlements form the connection between the commercial agreement with the customer and the operational execution of service work.
What are Service Contract entitlements?
Service Contract entitlements represent the services, benefits and conditions a customer is entitled to under an active Service Contract. Depending on the agreement, entitlements may include:
Preventive maintenance visits included in the contract.
Coverage for corrective maintenance or breakdown response.
Included labor hours or specific service activities.
Coverage for spare parts and materials.
Travel coverage or agreed travel charges.
Fixed prices or discounts for particular services.
Agreed service levels and response times.
The actual entitlements depend on the contract configuration. Not every Service Contract includes the same services or financial benefits.
Service Contracts and covered Service Objects
A Service Contract defines the agreement for a particular period and identifies the Service Objects or Object Structures to which its terms apply. This relationship is important because different Service Objects may be subject to different coverage arrangements, even when they belong to the same customer.
For example, a customer may have an agreement that includes preventive maintenance for certain installations while corrective repairs are charged separately.
By associating Service Objects with the appropriate Service Contract, HSO Service Management can determine the relevant contractual context when a Service Call is registered.
Coverage Types
Coverage Types describe the rights and obligations included in a Service Contract. They represent recognizable categories of service coverage, such as preventive maintenance, breakdown labor, spare parts, travel or inspections.
Coverage Types are used in conjunction with Contract Types and Service Level Definitions to determine which services are covered and how the associated transactions are treated.
For example, a contract may include preventive maintenance labor and travel while replacement parts remain chargeable. Another contract may provide broader coverage, including selected materials or corrective maintenance activities. This flexibility allows service organizations to offer different levels of coverage according to their commercial agreements.
Contract Types
A Contract Type defines the general commercial model of a Service Contract and brings together the applicable coverage arrangements. It also supports the definition of contract-related behavior, including pricing, invoicing and maintenance scheduling.
Contract Types can therefore be used to distinguish different service offerings, such as agreements based on periodic maintenance, broader service coverage or usage-related arrangements. The available Coverage Types and their pricing are defined as part of the Contract Type configuration.
Service Level Definitions
A Service Level Definition (SLD) determines how the contractual agreement is applied when a customer requests service. An SLD combines several important elements:
The Service Object scope to which the definition applies.
The Call Types that are allowed.
The default Call Type.
The applicable Coverage Type.
The Project Integration used for financial processing.
An SLD can differentiate between individual Service Objects, Object Groups or a broader object scope. For example, a Service Contract may allow preventive maintenance and repair requests but apply different coverage and financial treatment to each Call Type. A default SLD also provides the basis for handling service requests outside a specific Service Contract.
How entitlements affect Service Calls
When a Service Call is registered, the applicable Service Contract and SLD provide the context for determining the relevant service conditions. This influences which Call Types are available, which coverage applies and how subsequent service transactions are processed.
For example, consider a customer with a Service Contract that includes preventive maintenance but excludes corrective repairs. A planned maintenance Service Call may be covered under the agreement, while a corrective repair Service Call may result in chargeable labor and material transactions. Both requests can be managed through the same service process, but their financial treatment differs according to the applicable entitlement.
Financial treatment and Project Integration
Service Contract entitlements influence how costs and revenue are handled during service execution. Project Integration connects HSO Service Management with the Project Management and Accounting functionality of Microsoft Dynamics 365 for Finance and Operations. It determines the applicable project categories, line properties and financial treatment for different transaction types.
Together, the Service Level Definition, Coverage Type and Project Integration determine how service transactions are classified and whether they are chargeable to the customer. Depending on the agreement, services may be included in the contract price, subject to specific discounts or invoiced separately. This allows operational work to be registered consistently while the financial treatment reflects the contractual agreement.
Contract proposals and templates
Service Contracts are commonly prepared through Contract Proposals, allowing the proposed Service Objects, coverage, pricing and other conditions to be reviewed before the agreement becomes effective. Contract Templates can be used to standardize recurring service offerings. They combine predefined contract settings, including the Contract Type, SLD and other commercial conditions. Individual agreements can still be adapted to reflect customer-specific requirements.
Summary
Service Contract entitlements define what a customer can expect from a service agreement and how those commitments are applied during service execution. The main concepts are:
Service Contract – Defines the agreement, covered Service Objects, service obligations and commercial conditions.
Coverage Type – Identifies the specific rights and obligations included in the agreement.
Contract Type – Defines the commercial contract model and available coverage arrangements.
Service Level Definition – Determines how the contract applies to Service Calls, including allowed Call Types, coverage and Project Integration.
Project Integration – Controls the financial processing of service transactions in Microsoft Dynamics 365 for Finance and Operations.
Together, these concepts ensure that service activities are performed and financially processed according to the agreed contractual conditions. The detailed setup and management of Service Contracts, Coverage Types, Contract Types and Service Level Definitions are described in the Service Contracts and Setup & Configuration sections of this documentation.
Introduction
HSO Service Management is fully integrated with Microsoft Dynamics 365 for Finance and Operations and uses its standard business functionality to support the operational, logistical and financial aspects of service management. Rather than maintaining separate processes for service execution and financial administration, HSO Service Management connects Service Objects, Service Contracts, Service Calls and Service Tasks with the relevant functionality in Microsoft Dynamics 365 for Finance and Operations.
This integration enables organizations to manage service activities while using the existing infrastructure for projects, inventory, resources, accounting and invoicing. The integration with Project Management and Accounting is particularly important, as it provides the financial foundation for service-related transactions.
Project Management and Accounting
HSO Service Management is tightly integrated with the standard Project Management and Accounting module of Microsoft Dynamics 365 for Finance and Operations. Financial and logistical transactions generated through service activities are recorded as project transactions. Service Objects are associated with projects, while Service Calls can generate sub-projects under the Service Object's project or another selected project.
Service Task and Service Call registrations subsequently generate transactions against the relevant project structure. This provides a connection between service execution and financial administration, allowing costs and revenue to be recorded and analyzed in the context of individual Service Objects and Service Calls. The required project information is generated or assigned as service records are created and processed, allowing service users to perform their daily activities within HSO Service Management without normally having to work directly in the Project Management and Accounting module.
Project Integration configuration
Project Integration defines how transactions originating from HSO Service Management are processed within the Project Management and Accounting module. It determines the applicable project categories, journals and line properties for different transaction types, including labor hours, items, expenses, travel, revenue and depreciation.
The appropriate Project Integration is selected through the Service Level Definition (SLD), taking the applicable Service Contract and coverage conditions into account. For example, labor registered against a Service Task may be chargeable to the customer, included under a Service Contract or treated differently according to the applicable coverage. Project Integration provides the financial configuration required to process these transactions correctly.
The detailed configuration of Project Integration is described in the Setup & Configuration section of this documentation.
Inventory and Warehouse Management
HSO Service Management uses standard Inventory and Warehouse Management functionality to support material consumption and logistical processes. Service Tasks may require spare parts or other materials, which are handled through the relevant inventory processes in Microsoft Dynamics 365 for Finance and Operations. Depending on the scenario and configuration, this can involve item requirements, Sales Orders, inventory reservations and transfers.
Standard inventory settings remain applicable, including item availability, item groups, item model groups, warehouses, locations and serial number requirements. Inventory integration also supports repair and workshop processes, where materials may need to be received, stored, consumed or transferred during service execution. This ensures that service-related material movements remain connected to the organization's inventory administration.
Resource management and scheduling
Planning and scheduling Service Tasks relies on resource and capacity information maintained within Microsoft Dynamics 365 for Finance and Operations. Resources can include service engineers and other employees, as well as non-human resources such as tools, workstations and machines.
Resource availability, calendars, capabilities and applicable requirements can be considered when assigning resources to Service Tasks. Scheduling can also create capacity reservations to reflect planned work. By using the resource information available in Microsoft Dynamics 365 for Finance and Operations, HSO Service Management supports coordinated planning of service activities alongside other operational processes.
Detailed planning and scheduling functionality is covered separately in this documentation.
Sales and customer-related processes
HSO Service Management also integrates with standard sales processes. For example, delivered products can be registered through equipment or object lists and, where applicable, used to create Service Objects. This connects the original sales process with subsequent maintenance, repairs and service history.
Sales Orders may also be used when resolving certain Service Calls, such as requests involving the delivery of replacement parts without a separate Service Task. Service Quotations provide additional functionality for preparing and managing quotations for service work, including the expected labor, materials and other transactions.
Financial accounting and invoicing
Financial transactions originating from service activities are processed through the standard financial functionality of Microsoft Dynamics 365 for Finance and Operations. Project transactions follow the applicable posting profiles, account structures, financial dimensions and other accounting requirements configured within the system.
After service work has been completed and the relevant Service Call is ready for financial processing, invoice proposals can be generated and posted through Project Management and Accounting. The financial treatment of individual transactions depends on the applicable Service Contract, coverage conditions and Project Integration configuration.
This approach allows service organizations to maintain consistent financial administration while supporting different service billing arrangements, including chargeable work and services covered by contractual agreements.
Integration with Mobile Field Service
HSO Service Management can be extended with Mobile Field Service to support service engineers working in the field. Service Tasks can be dispatched to the mobile application, allowing engineers to access assigned work and register execution information, including labor, materials and other relevant service details.
The registered information is synchronized with HSO Service Management for further operational and financial processing within Microsoft Dynamics 365 for Finance and Operations. Mobile Field Service supports both online and offline working scenarios. Its functionality and configuration are described separately in the relevant product documentation.
Importance of consistent configuration
Because HSO Service Management uses standard functionality from multiple Microsoft Dynamics 365 for Finance and Operations modules, the configuration of these modules must be considered together. For example, incorrect Project Integration settings can affect financial postings, while missing inventory configuration can prevent materials from being processed correctly. Similarly, incomplete resource or calendar information can influence scheduling and capacity reservations.
Successful implementation therefore requires alignment between Service Management, Project Management and Accounting, Inventory, Warehouse Management, Finance, Sales and Resource Management. This ensures that service activities can be processed consistently from initial registration through execution, completion and invoicing.
Summary
The integration with Microsoft Dynamics 365 for Finance and Operations provides the operational and financial foundation for HSO Service Management. The main integration areas include:
Project Management and Accounting – Project structures, service transactions, costs, revenue and invoicing.
Project Integration – Transaction classification, project categories, line properties and financial treatment.
Inventory and Warehouse Management – Material consumption, stock movements and repair logistics.
Resource management – Resource availability, capabilities, calendars and capacity reservations.
Sales – Equipment registration, Sales Orders and service-related sales processes.
Finance – Financial postings, accounting structures and invoice processing.
Mobile Field Service – Mobile execution and registration of Service Tasks.
Together, these integrations allow HSO Service Management to support the complete service lifecycle while using the standard business processes and financial controls of Microsoft Dynamics 365 for Finance and Operations.
Introduction
This glossary provides an overview of the terminology used throughout HSO Service Management. It serves as a reference for understanding the functional concepts, configuration elements and operational processes described in this documentation. The terminology is organized by functional area to make individual concepts easier to locate.
Service Objects
| Term | Description |
|---|---|
| Service Object | An identifiable entity on which service is performed, such as equipment, an installation or a location, with its own operational and financial service history. |
| Object Type | The primary classification of a Service Object, defining common properties, hierarchy rules and configuration defaults. |
| Object Structure | The hierarchical arrangement of Service Objects, sub-objects and components within a Service Contract. |
| Component | An element within an Object Structure on which Service Operations are performed, without necessarily requiring separate financial or logistical tracking. |
| Service Object Pool | A grouping of similar Service Objects sharing common service conditions and coverage. |
| Anonymous Pool | A pool representing a quantity of non-individually identified items, with service history maintained at pool level. |
| Object Template | A predefined structure used to create the required components for a particular Object Type. |
| Meter / Counter | A registration entity associated with a component that stores dated readings for usage monitoring and maintenance purposes. |
Service Calls
| Term | Description |
|---|---|
| Service Call | The central record for a service request, tracking customer information, progress, related Service Tasks, operational history and financial closure. |
| Call Type | A classification identifying the nature of a Service Call and influencing the applicable service process, coverage and financial treatment. |
| Priority | The urgency assigned to a service request, potentially determined through a severity matrix. |
| Service Note | Operational information made available on Service Calls and Service Tasks from relevant customer, Service Object, maintenance or warranty context. |
| Service Call history | The recorded history of Service Call changes and handling activities throughout its lifecycle. |
Service Tasks
| Term | Description |
|---|---|
| Service Task | A unit of work assigned to a resource, planned and executed as part of a Service Call. |
| Event Code | A reusable definition of service work that, together with an Object Type, can determine forecasted duration, materials, Service Operations and revenue. |
| Service BOM | A predefined list of spare parts associated with an Object Type and Event Code, which can be used to populate Service Task item requirements. |
| Service Operation | A specific activity, inspection or measurement performed on a component, including execution feedback and return values. |
| Registered Service Operations | Historical records of completed Service Operations, including execution feedback and return values. |
| Resource Requirements | Requirements relating to skills, capabilities, certifications or location that influence which resources are suitable for a Service Task. |
Service Contracts
| Term | Description |
|---|---|
| Service Contract | An agreement defining the services, rights, obligations and commercial conditions applicable to specified Service Objects over a particular period. |
| Service Contract Proposal | A proposed agreement or contract change that can be evaluated before being converted into an effective contract period. |
| Contract Type | A configuration defining the commercial contract model, available coverage arrangements and relevant maintenance and invoicing behavior. |
| Coverage Type | A definition of specific service rights and obligations, such as covered labor, maintenance, materials or travel. |
| Service Level Agreement (SLA) | An agreement defining the level of service a customer can expect, often expressed through response or handling times. |
| Service Level Definition (SLD) | A configuration combining Service Object scope, allowed Call Types, default Call Type, Coverage Type and Project Integration. |
| Contract Template | A predefined configuration used to standardize recurring Service Contract offerings and proposals. |
| Contract Trade Agreement | A pricing arrangement defining agreed item prices or discounts for specified Service Contracts or contract groups. |
Planning and Scheduling
| Term | Description |
|---|---|
| Resource | An employee or non-human resource, such as a machine, tool or workstation, that can be assigned or reserved for service activities. |
| Resource selection setup | Configuration used to identify suitable resource groups based on region and resource requirements. |
| Region Code | A geographical or organizational classification used for Service Objects and resource planning. |
| Capacity reservation | A reservation of resource availability for a planned Service Task or other service activity. |
Maintenance and Planned Service
| Term | Description |
|---|---|
| Preventive Maintenance | Maintenance performed to prevent failures or deterioration, based on predefined schedules, intervals or equipment usage. |
| Planned Maintenance | Periodic maintenance activities projected and generated according to Service Contract schedules, resulting in planned Service Calls and Service Tasks. |
| Planned Service | A process for selecting Service Objects and preparing service activities outside regular contract-based maintenance schedules, such as product recalls, technical modifications or service campaigns. |
| Service Schedule | A definition of planned maintenance based on frequency or interval. |
| Service Schedule Selection | Configuration used to determine which Service Schedule applies within a Service Contract or proposal. |
| Visit Schedule | A schedule defining planned service visits and the associated maintenance visit identifiers. |
Service Quotations
| Term | Description |
|---|---|
| Service Quotation | A quotation for proposed service work, including estimated labor, materials, expenses and pricing, which can be used as the basis for subsequent service execution. |
Repair Centre
| Term | Description |
|---|---|
| Repair Centre | The workshop process for receiving, repairing and returning Service Objects through Service Calls and Service Tasks. |
Financial integration and invoicing
| Term | Description |
|---|---|
| Project Integration | The configuration connecting service transactions with Project Management and Accounting in Microsoft Dynamics 365 for Finance and Operations, including project categories and line properties. |
| Project Category | A classification used for project transactions that influences financial posting, pricing and reporting. |
| Line Property | A project transaction attribute used in determining financial and invoicing treatment. |
| Visit Tariff | Pricing configuration used to determine applicable charges for service visits or travel. |
| Revenue Period | The period used to allocate Service Contract revenue, which may differ from the invoice period. |
| Invoice Schedule | The schedule defining when recurring Service Contract invoices are generated. |
Field Service
| Term | Description |
|---|---|
| Mobile Field Service | The mobile application supporting service engineers in executing and registering assigned Service Tasks, including online and offline scenarios. |
Using this glossary
The glossary provides a common terminology for the processes and functionality described throughout HSO Service Management. Each functional area is covered in greater detail in the corresponding chapters of this documentation, including configuration requirements, operational procedures and integration with Microsoft Dynamics 365 for Finance and Operations.